<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">

<title>svn-buildpackage - maintaining Debian packages with Subversion - Getting started</title>

</head>

<body>

<p><a name="ch-start"></a></p>
<hr>

<p>
[ <a href="ch-intro.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch-intro.html">1</a> ]
[ 2 ]
[ <a href="ch-import.html">3</a> ]
[ <a href="ch-tasks.html">4</a> ]
[ <a href="ch-reference.html">5</a> ]
[ <a href="ch-misc.html">6</a> ]
[ <a href="ch-import.html">next</a> ]
</p>

<hr>

<h1>
svn-buildpackage - maintaining Debian packages with Subversion
<br>Chapter 2 - Getting started
</h1>

<hr>

<p>
Besides of the packages that are installed by dependencies when you install
<samp>svn-buildpackage</samp>, you may need <samp>ssh</samp> and the obligatory
tool chain: <samp>dpkg-dev</samp>, <samp>build-essential</samp> and all the
packages they pull into the system.
</p>

<hr>

<h2><a name="s-quick"></a>2.1 Quick guide</h2>

<p>
Here is a quick guide for those who wish to build an existing package using an
existing, public available SVN repository.  To create own repositories, skip
this section and look for more details below.
</p>
<ul>
<li>
<p>
svn co &lt;svn://server/path/to/trunk&gt; package
</p>
</li>
</ul>
<ul>
<li>
<p>
mkdir tarballs
</p>
</li>
</ul>
<ul>
<li>
<p>
cp dir-where-you-keep-the-source/package_version.orig.tar.gz tarballs/
</p>

<p>
NOTE: you need the upstream source tarballs, stored under a usual
dpkg-source-compatible filename in tarballs/
</p>
</li>
</ul>
<ul>
<li>
<p>
cd package
</p>
</li>
</ul>
<ul>
<li>
<p>
svn-buildpackage -us -uc -rfakeroot
</p>
</li>
</ul>

<hr>

<h2><a name="s-basics"></a>2.2 Basic svn usage</h2>

<p>
You need only few commands to start using svn with svn-buildpackage scripts.
If you wish to learn more about it, read parts of the the <code><a
href="http://svnbook.red-bean.com/html-chunk/">Subversion Book</a></code>.  The
most used commands are:
</p>
<ul>
<li>
<p>
<samp>add</samp> -- put new files unto the revision contol
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>rm</samp> -- remove the files from the repository
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>mv</samp> -- move files around, leting revision control system know about
it
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>commit</samp> -- commit your changes to the repository
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>resolved</samp> -- tell svn that you have resolved a conflict
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>diff</samp> -- creates a &quot;diff -u&quot; between two versions,
specified by file revision number or by date.  See the <samp>diff --help</samp>
output.
</p>
</li>
</ul>
<ul>
<li>
<p>
<samp>cat -r Revision</samp> -- useful to browse in some previous revision of
the file
</p>
</li>
</ul>

<p>
If you are familiar with CVS you will probably know almost all you need.
</p>

<hr>

<h2><a name="s-svncreate"></a>2.3 Creating Subversion repository</h2>

<p>
The main Subversion repository is easily created with:
</p>

<pre>
     svnadmin create repo-directory
</pre>

<p>
For our example, we choose the name <samp>svn-deb-repo</samp> and put it in
<samp>/home/user</samp>.
</p>

<p>
If you plan to keep many packages in the one repository including upstream
tarballs, consider to put it on a hard disk with much free space and good
performance (especially short disk access times) since the repository will grow
and the filesystem may become fragmented over time.
</p>

<hr>

<h2><a name="s-multidev"></a>2.4 Using by multiple developers</h2>

<p>
Multiple developers with local access to the repository may share it using a
common group.  To do so, create a new group and add all developers to it.  Run
&quot;chgrp -R sharedGroup repdir ; chmod -R g+s repdir&quot; for the shared
group and the repository directory.  Now, on local access to this repository
everybody will create files with the appropriate group setting.  However, the
developers will need to set a liberal umask before using svn (like
&quot;0022&quot;).
</p>

<p>
If somebody resists to do so, there is still a brute-force solution: fix the
permissions with a post-commit script.  However, this is an &quot;unsound&quot;
solution and may lead to ALL KINDS OF PROBLEMS.  MAKE SURE THAT YOU ARE AWARE
OF THE POSSIBLE CONSEQUENCES BEFORE YOU OPEN THE PANDORA BOX.  See <code><a
href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240630">Debian
BTS</a></code> for details.  When you damage your repository, don't blame me
and remember that there is &quot;svnadmin recover&quot;.
</p>

<pre>
     #!/bin/sh
     
     # POST-COMMIT HOOK
     # The following corrects the permissions of the repository files
     
     REPOS=&quot;$1&quot;
     REV=&quot;$2&quot;
     
     chgrp -R sharedGroup $REPOS
     # replace sharedGroup with your group
     chmod -R g+r $REPOS
     chmod -R g+w $REPOS
</pre>

<hr>

<h3><a name="s-svn-d-o"></a>2.4.1 SVN over SSH</h3>

<p>
To run Subversion over SSH, you basically need a shell on the target system and
a subversion repository located there which is created following the
description above.  The repository must be configured for access by the system
users of the remote system.
</p>

<p>
Assuming that your user name on the client system is the same as on the server
side, there is not much to configure.  Just change the protocol specificaton
from <samp>file://</samp> to
<samp>svn+ssh://remoteusername@server-hostname</samp> in all examples showed in
this manual.
</p>

<p>
Note that during svn-buildpackage tools actions a lot of SSH calls can be made
and so the user is asked for his login data.  The regular method to deal with
that is using an SSH key authentication method together with ssh-agent and
ssh-add to cache the passphrase in memory.  Another approach, which also brings
a significant speed boost, is using a cached SSH connection.  This can be done
with a new feature of OpenSSH (see <code><a
href="http://gcc.gnu.org/wiki/SSH%20connection%20caching">GCC SSH connection
caching howto</a></code>) or a third-party tool like <samp>fsh</samp>.
</p>

<p>
If you wish to use fsh over ssh you could specify a custom transport method in
subversions's configuration.  To do so, edit the file
<samp>~/.subversion/config</samp> and add the section <samp>[tunnels]</samp> to
it, following by your custom transport definition.  Example:
</p>

<pre>
     # personal subversion config with custom ssh tunnel command
     [tunnels]
     # SSH account on svn.d.o
     # compression is enabled in the ssh config
     deb = fsh -l blade
     # SSH account for NQ intranet, set fix username
     nq = ssh -C -l zomb
</pre>

<p>
You can use the new defined tunnels in a similar ways as described above but
replace <samp>svn+ssh</samp> with <samp>svn+tunnelname</samp>, so the final URL
looks like:
</p>

<pre>
     svn+deb://svn.debian.org/svn/myproject/ourpackage/trunk
</pre>

<p>
.
</p>

<hr>

<h3><a name="s-anon"></a>2.4.2 Anonymous access</h3>

<p>
You can allow outsiders to have anonymous (read-only) access using the svnserve
program, as described in the Subversion documentation.
</p>

<p>
Another method is using HTTP/WebDAV with Apache2.  More about a such setup can
be found in the Subversion Book and the <code><a
href="http://wiki.debian.net/?SubversionApache2SSLHowto">SubversionApache2SSL
Howto</a></code>.  <code><a
href="http://svn.debian.org/">svn.debian.org</a></code> is an example site
granting anonymous access to some selected projects hosted there.
</p>

<hr>

<p>
[ <a href="ch-intro.html">previous</a> ]
[ <a href="index.html#contents">Contents</a> ]
[ <a href="ch-intro.html">1</a> ]
[ 2 ]
[ <a href="ch-import.html">3</a> ]
[ <a href="ch-tasks.html">4</a> ]
[ <a href="ch-reference.html">5</a> ]
[ <a href="ch-misc.html">6</a> ]
[ <a href="ch-import.html">next</a> ]
</p>

<hr>

<p>
svn-buildpackage - maintaining Debian packages with Subversion
</p>

<address>
$LastChangedDate: 2005-09-23 16:17:33 +0200 (Fr, 23 Sep 2005) $<br>
<br>
Eduard Bloch<br>
<br>
</address>
<hr>

</body>

</html>

